Password-based management of encrypted files

ABSTRACT

Embodiments include methods for managing encrypted files by storing a user password hash including a predetermined function of the user password associated with that user ID and the secret keys. Aspects also include, in response to receipt from a user computer of an input password and a the user ID for a required encrypted file, communicating with authentication servers to implement a key-reconstruction protocol in which each server computes first and second hash values for the required encrypted file. The file management server uses the first hash values to compute an input password hash including the predetermined function of the input password and the secret keys, checks if the input password hash matches the user password hash for the received user ID, and reconstructs the encryption key for the required encrypted file.

BACKGROUND

The present invention relates generally to password-based encrypted file management, and more specifically to management of encrypted user files at a server whereby decryption of user files is dependent on authentication of user passwords.

Servers which are accessible to user computers over networks are often required to manage files containing sensitive user information. For example, online services such as booking portals, app-stores, online stores, etc., may store files containing user address details and payment data such as credit card numbers. Another example is where users upload arbitrary files to a server offering a secure storage facility, so that access to files is restricted to the user in question. Clearly, user files should be encrypted in such scenarios, otherwise a security breach would leak the plaintext user data. Data security then relies on security of the cryptographic keys used for encryption of the user files.

Various services and user-side applications are available for encrypting user data before uploading to cloud storage. Encryption keys here are derived from user passwords, with dedicated software/secure storage typically required at user computers. Due to the low entropy of typical user passwords, password-derived keys can be vulnerable to offline attack if the host server is corrupted. In particular, an adversary obtaining some information that allows him to verify whether a password guess was correct, can then use that information to detect the correct password via brute-forcing, i.e. testing all possibilities.

SUMMARY

According to at least one embodiment of the present invention there is provided a server system comprising a file management server and n≧1 authentication servers for communication with the file management server via a network. The file management server is operable for communication with user computers via the network and for managing encrypted files, each encrypting a user file associated with a user ID under a respective encryption key K_(f) encoding a user password associated with that user ID. Each server of the system stores a respective secret key k_(i). The file management server stores, for each user ID, a user password hash comprising a predetermined function of the user password associated with that user ID and the secret keys k_(i). The servers of the system are adapted such that, in response to receipt from a user computer of an input password and a the user ID for a required encrypted file, the file management server communicates with λ authentication servers, 1≦λ≦n, to implement a key-reconstruction protocol. In this key-reconstruction protocol, each server computes first and second hash values, including the secret key k_(i) thereof, for the required encrypted file. The file management server uses the first hash values to compute an input password hash comprising the predetermined function of the input password and the secret keys k_(i), checks if the input password hash matches the user password hash for the received user ID, and, if so, reconstructs the encryption key K_(f) for the required encrypted file. The reconstructed key K_(f) encodes the input password and reconstruction of the key K_(f) requires use of the second hash values. The file management server then decrypts the required encrypted file using the reconstructed key K_(f).

At least one further embodiment of the present invention provides a method for managing encrypted files at a file management server of such a server system.

Embodiments of the invention will be described in more detail below, by way of illustrative and non-limiting example, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of a data processing system including a server system embodying the invention;

FIG. 2 is a generalized schematic of a computer in the server system of FIG. 1;

FIG. 3 indicates steps performed in a key-reconstruction operation of the server system;

FIG. 4 indicates more detailed steps of a key-reconstruction operation in a first embodiment;

FIG. 5 indicate steps of a refresh operation in the first embodiment;

FIG. 6 indicates steps of a key-reconstruction operation in a second embodiment;

FIG. 7 is a schematic representation of an exemplary server implementation for the second embodiment; and

FIG. 8 indicates steps of a refresh operation in the second embodiment.

DETAILED DESCRIPTION

FIG. 1 is a schematic block diagram of a data processing system incorporating a server system 1 embodying the invention. The server system 1 comprises a file management server 2, denoted by S₀, and a set of n≧1 authentication servers 3, denoted by S₁ to S_(n). The file management server 2 is adapted for communication with the authentication servers 3 and a plurality of user computers 4 via a network 5. The network 5 may in general comprise one or more component networks and/or internetworks, including the Internet. The user computers 4 are shown as general-purpose personal computers (PCs) in this example, but may equally be implemented by other computer devices such as mobile phones, tablet computers, personal music players, palmtop devices, etc. The file management server 2 manages encrypted files which are held in storage, represented by database 6 in the figure, operatively associated with the server 2. Each of these encrypted files encrypts a user file, which is associated with a user ID, under a respective encryption key K_(f) for that user file. The user IDs (e.g. user names) serve to identify respective users who access the server system 1 via user computers 4 in operation. The encryption key K_(f) for a given user file encodes a user password, associated with the user ID for that file, along with one or more further values as discussed below. The file management server 2 is adapted to communicate with authentication servers 3 to implement a key-reconstruction protocol and related operations detailed below. In particular, the encryption keys K_(f) are not stored in server system 1. Decryption of an encrypted file relies on reconstruction of the corresponding encryption key K_(f) via the key-reconstruction protocol. Reconstruction of keys via this protocol is dependent on authentication of user passwords by file management server 2 as explained below.

The number n of authentication servers can vary for different embodiments. In preferred embodiments, n>1. In general, higher values of n offer greater system security, and the value of n can be selected as desired depending on the particular protocol operation and required level of security. The authentication servers 3 may be located at the same location as file management server 2 or at one or more different locations, and may be controlled by the same entity as the file management server or by one or more different entities. Distribution and control of the servers 2, 3 can thus be selected according to security requirements for a given system.

A high-level abstraction of functional components of the servers 2, 3 is shown in FIG. 1. File management server 2 is indicated as comprising a communications interface (I/F) 7 for communications via network 5, file management logic 8, and storage 9. The file management logic 8 provides functionality for implementing steps of the key-reconstruction and related operations detailed below. In general, this control logic can be implemented in hardware or software or a combination thereof. Storage 9 stores various data used by the control logic 8 in operation. This includes a password data set {uid:PH} containing a user password hash PH, described further below, for the user ID uid of each registered user of server system 1. The file management server 2 also stores a cryptographic key k₀ which is secret to server 2. Each authentication server 3 is similarly shown as comprising a communications interface 11, authentication logic 12 and storage 13. The authentication logic 12 (which can again be implemented in hardware or software or a combination thereof) provides functionality for use in the key-reconstruction and related operations described below. Storage 13 stores data used by authentication logic 12 in operation. In particular, each authentication server S₁ to S_(n) stores a respective cryptographic key k₁ to k_(n) which is secret to that server.

Each of the functional blocks of servers 2, 3 in FIG. 1 may be implemented in general by one or more functional components which may be provided by one or more computers. In particular, each of servers 2, 3 may be implemented by computing apparatus comprising one or more general- or special-purpose computers, each comprising one or more (real or virtual) machines, providing functionality for implementing the operations described herein. Exemplary implementations will be described further below. The file management and authentication logic 8, 12 of these servers may be described in the general context of computer system-executable instructions, such as program modules, executed by a computing apparatus. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. The computing apparatus may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, data and program modules may be located in both local and remote computer system storage media including memory storage devices. The database 6 containing encrypted files may be similarly provided in any storage operatively associated with file management server 2, including local and remote storage media.

FIG. 2 is a block diagram of exemplary computing apparatus for implementing a computer of server system 1. The computing apparatus is shown in the form of a general-purpose computer 15. The components of computer 15 may include processing apparatus such as one or more processors represented by processing unit 16, a system memory 17, and a bus 18 that couples various system components including system memory 17 to processing unit 16.

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Computer 15 typically includes a variety of computer readable media. Such media may be any available media that is accessible by computer 15 including volatile and non-volatile media, and removable and non-removable media. For example, system memory 17 can include computer readable media in the form of volatile memory, such as random access memory (RAM) 19 and/or cache memory 20. Computer 15 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 21 can be provided for reading from and writing to a non-removable, non-volatile magnetic medium (commonly called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can also be provided. In such instances, each can be connected to bus 18 by one or more data media interfaces.

Memory 17 may include at least one program product having one or more program modules that are configured to carry out functions of embodiments of the invention. By way of example, program/utility 22, having a set (at least one) of program modules 23, may be stored in memory 17, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules 23 generally carry out the functions and/or methodologies of embodiments of the invention as described herein.

Computer 15 may also communicate with: one or more external devices 24 such as a keyboard, a pointing device, a display 25, etc.; one or more devices that enable a user to interact with computer 15; and/or any devices (e.g., network card, modem, etc.) that enable computer 15 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 26. Also, computer 15 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 27. As depicted, network adapter 27 communicates with the other components of computer 15 via bus 18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer 15. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

The user files encrypted in system 1 may be uploaded by users for secure storage or may otherwise contain security-sensitive information associated with respective users, such as payment data for use in user transactions. Encryption keys K_(f) are generated, and user files are encrypted and stored in database 6, as part of a setup procedure described below. Decryption of a file stored in database 6 may be initiated at request of a user, e.g. to retrieve a file previously uploaded by the user, or initiated by file management server 2 for use in some interaction with a user, e.g. to retrieve payment data for a transaction. To decrypt a required file, the encryption key K_(f) for that file must be reconstructed by server system 1. To reconstruct the key K_(f), file management server 2 must first authenticate a user password p previously registered with server 2 for the user in the setup procedure described below. This setup procedure involves generation of the user password hash PH which is stored in password data set {uid:PH} for that user. The user password hash PH comprises a predetermined function, denoted by F in the following, of the user password p associated with the user's ID uid and the secret keys k_(i) of servers S₀ to S_(n). This user password hash PH is then used to authenticate a user password in the subsequent key-reconstruction protocol.

FIG. 3 gives an overview of the main steps performed by server system 1 in the key-reconstruction operation for decryption of a required file. Note that, in this and subsequent flow diagrams, steps may be performed in a different order to that shown, and some steps may be performed concurrently as appropriate. (For simplicity, operation will be described here for a scenario in which a single encrypted file is stored for a given user. However, system operation can readily accommodate a plurality of files per user as explained below). The file decryption process requires a user to connect to file management (FM) server 2 from a user computer 4 over network 5. The user supplies his user ID uid and an input password p′ (i.e. an attempt at his user password p as previously registered with FM server 2 in the setup procedure). The login data (uid, p′) is received by FM server 2 in step 30 of FIG. 3. In step 31, the control logic 8 of FM server 2 initiates the key-reconstruction protocol. This protocol requires the FM server 2 to communicate via network 5 with λ of the authentication servers 3, where 1≦λ≦n. The number λ here depends on implementation details discussed below. To initiate the protocol, FM server 2 sends a message to each of the λ authentication servers via communications interface 7. The contents of this message depend on protocol implementation and detailed examples are given below, but the message typically includes at least the user ID uid associated with the file to be decrypted.

In step 32 of FIG. 3, the control logic 8, 12 of each server S_(i) involved in the key-reconstruction protocol (i.e. FM server 2 and each of the λ authentication servers 3) computes first and second hash values, denoted here by h_(i) ¹ and h_(i) ² respectively, for the required encrypted file. These hash values can be generated in various ways as illustrated by examples below, and may include various data, such as the uid, associated with the required file. However, the values h_(i) ¹ and h_(i) ² generated by a given server S_(i) each include the secret key k_(i) stored by that server. In step 33, the λ authentication servers 3 send the resulting hash values h_(i) ¹, h_(i) ² back to FM server 2 via network 5. In step 34, the FM logic 8 of FM server 2 uses the first hash values h_(i) ¹ generated in step 32 to compute an input password hash PH′. The resulting input password hash PH′ comprises the predetermined function F of the input password p′ and the secret server keys k_(i). That is, the form of input password hash PH′ corresponds directly to that of the user password hash PH, but contains the input password p′ in place of the user password p. Next, in step 35, the FM logic 8 checks if the input password hash PH′ matches the user password hash PH pre-stored for the received user ID. If PH′ matches PH, indicated by a “Yes” (Y) at decision step 35, then the input password p′ equals the user password p. In this case, operation proceeds to step 36 in which the logic 8 of FM server 2 reconstructs the encryption key K_(f) for the required encrypted file. The reconstructed key K_(f) encodes the input password p′ (now authenticated via step 35 as equal to user password p), plus the further value(s) encoded in the key. The key reconstruction step requires use of the second hash values h_(i) ² computed in step 32, and hence use of the secret server keys k_(i) in these hash values. The hash values h_(i) ² may themselves encode the input password p′ and/or one or more of the further value(s) encoded in K_(f). Alternatively, or in addition, the hash values h_(i) ² may be used in generating such further value(s) required to reconstruct K_(f). Examples of such key-reconstruction processes are described below. In each case, however, key-reconstruction requires use of the input password p′ and, via the second hash values h_(i) ¹, the secret server keys k_(i), and only proceeds if the input password p′ is authenticated in step 35 as the correct user password p for the required file. In step 37, the FM logic 8 then decrypts the encrypted file using the reconstructed key K_(f). Depending on the application scenario, the FM server may send the decrypted file to the user, or otherwise use the decrypted data in further interaction with the user, and the decryption operation is complete. If, however, the password hashes PH′ and PH do not match, i.e. decision “No” (N) at step 35, then the input password p′ does not match the user password p for the user ID. The FM server 2 then aborts the decryption process in step 38, and may notify the user that authentication has failed.

The above operation provides secure management of encrypted user files whereby encryption keys can only be reconstructed by FM server 2 via interaction with one or more authentication servers 3, using the secret server keys k_(i) via the second hash values h_(i) ², and on successful authentication of user passwords via the first hash values h_(i) ¹. The FM server can thus actively check user passwords before securely reconstructing encryption keys on behalf of authorized users. These features offer secure and highly efficient key reconstruction protocols. No software or strong secrets are required at user computers 4, and the user need only interact with a single server, i.e. FM server 2, while encryption keys are protected against offline attack on user passwords if the FM server is compromised. An adversary must corrupt at least λ authentication servers as well as the FM server to compromise the system. In preferred embodiments λ=n, requiring corruption of all servers to compromise security. Moreover, the above system provides the basis for proactive security in server system 1, whereby secret server keys k_(i) can be refreshed without requiring recomputation of encryption keys or resubmission of user passwords. This feature, explained for preferred embodiments below, further enhances security in that subversion of system 1 would require corruption of all the necessary servers within the same time period between key-refreshes.

A first preferred embodiment of the above system will be described with reference to FIGS. 4 and 5. In this embodiment, the encryption key K_(f) for an encrypted file further encodes a random salt s for that file. FM server 2 stores a salt mask X which encodes the salt s and the second hash values h_(i) ². The salt mask X is computed by FM server 2, via interaction with authentication servers 3 to generate the second hash values h_(i) ², in the set up procedure for the file, and the salt s is then deleted. In this embodiment, the salt mask X comprises a modulo-2 sum of the salt s and the second hash values h_(i) ², i.e. X=s⊕_(i=0) ^(n)h_(i) ², where ⊕ represents modulo-2 addition. Reconstruction of the encryption key K_(f) for a file then requires reconstruction of the salt s for that file. FIG. 4 indicates steps of the key-reconstruction operation for decryption of a file in this embodiment. For simplicity, operation again assumes that a single encrypted file is stored for a given user, but accommodation of multiple user files is a straightforward matter as explained below.

The user ID uid and input password p′ supplied by the user are received by FM server 2 in step 40 of FIG. 4. In step 41, the FM server 2 initiates the key-reconstruction protocol by sending the received user ID uid to each authentication server server S₁ to S_(n) (i.e. λ=n in this embodiment). In step 42, the control logic 8, 12 of each server S₀ to S_(n) computes the first and second hash values h_(i) ¹ and h_(i) ². In this embodiment, the hash values h_(i) ¹, h_(i) ² are computed by hashing respective inputs which include the user ID uid and the secret key k_(i) of the server S₁. In step 43, the n authentication servers S₁ to S_(n) send their hash values h_(i) ¹, h_(i) ² back to FM server 2. In step 44, the FM server 2 uses the first hash values h_(i) ¹ to compute an input password hash PH′ as a modulo-2 sum of an initial hash value h, which encodes the user password p′, and the first hash values h_(i) ¹ of all servers. That is, PH′=h(p′) ⊕_(i=0) ^(n)h_(i) ¹. For example, the initial hash value h may be computed by FM server 2 by hashing an input comprising the input password p′ and the user ID uid. The resulting input password hash PH′ comprises the same function F of the input password p′ as used to compute the user password hash PH from the user password p during setup. Thus, the pre-stored user password hash PH here comprises a modulo-2 sum of the initial hash value h, encoding user password p, and the first hash values: PH=h(p) ⊕_(i=0) ^(n)h_(i) ¹. Next, in step 45, the FM server 2 checks if the input password hash PH′ matches the user password hash PH for the user ID uid. If so, operation proceeds to step 46 in which the FM server reconstructs the salt s from the salt mask X pre-stored for the required file and the second hash values h_(i) ². In particular, the salt s is computed as a modulo-2 sum of the salt mask X and the second hash values h_(i) ²: s=X ⊕_(i=0) ^(n) _(i) ². In step 47, FM server 2 then reconstructs the encryption key K_(f) by encoding the input password p′ and the reconstructed salt s in like manner to production of the key from the salt and user password during setup. For example, the encryption key K_(f) may be produced by hashing an input comprising the input password p′ and the reconstructed salt s. In step 48, the FM server then decrypts the required file using the reconstructed key K_(f), and the operation is complete. Reverting to decision step 45, if the password hashes PH′ and PH do not match here, then the decryption process is aborted in step 49 and operation terminates.

The above construction, using modulo-2 addition, provides a simple and efficient protocol in which the secret keys k_(i) of servers S_(i) can be refreshed in operation of system 1. In particular, each server S₀ to S_(n) of this embodiment is adapted to periodically replace the current secret key k_(i) thereof with a new secret key. The time periods, or “epochs”, for which the keys k_(i) are refreshed may be defined in various ways in the system. For example, the refresh operation may be performed automatically for epochs of a predetermined duration, and/or a new epoch may be initiated in response to detection of an attack on system 1. An example of the refresh procedure is illustrated in FIG. 5. In this example, FM server 2 initiates the refresh process by sending a refresh instruction to authentication servers S₁ to S_(n) in step 50. The refresh instruction includes the user IDs uid_(j) of all users j=0, 1, 2, . . . , etc. with encrypted files in system 1. In step 51, each server S₀ to S_(n) chooses a new secret key k_(i)′ to replace the current secret key k_(i) of that server. In step 52, each server S_(i) then computes first and second update values, denoted by U_(i,j) ¹ and U_(i,j) ² here, for the encrypted file of each user j. The first update value U_(i,j) ¹ is a modulo-2 sum of the first hash value h_(i,j) ¹ for the file, computed using the current secret key k_(i), and that first hash value h_(i,j) ¹ computed using the new secret key k_(i)′. That is: U_(i,j) ¹=h_(i,j) ¹(k_(i)) ⊕h_(i,j) ¹(k_(i)′). Similarly, the second update value U_(i,j) ² is a modulo-2 sum of the second hash value h_(i,j) ¹ for the file, computed using the current secret key k_(i), and that second hash value h_(i,j) ² computed using the new secret key k_(i)′, i.e. U_(i,j) ²=h_(i,j) ² (k_(i)) ⊕ h_(i,j) ²(k_(i)′). In step 53, the authentication servers S₁ to S₁, send their update values U_(i,j) ¹ and U_(i,j) ² to FM server 2, and delete the old secret key k_(i) setting k_(i)←k_(i)′. Then, in step 54, FM server 2 updates the user password hash PH_(j) for each encrypted file by modulo-2 addition with each first update value U_(i,j) ¹. That is, PH_(j)(new)=PH_(j)(old) ⊕_(i=0) ^(n)U_(i,j) ¹. Similarly, in step 55, FM server 2 updates the salt mask for each file by modulo-2 addition with each second update value U_(i,j) ². That is, X_(j)(new)=X_(j)(old) ⊕_(i=0) ^(n)U_(i,j) ². In each case, the modulo-2 addition operation results in cancellation of the values based on the old keys k_(i) and insertion of corresponding values based on new keys k_(i)′. The FM server 2 then deletes its old key k₀, setting k₀←k₀′, and the refresh operation is complete. The password hashes PH and salt masks X for all files are thus updated for use with the new server keys k_(i) in the ensuing epoch.

The above refresh process provides proactive security in server system 1, allowing server keys to be refreshed as required without requiring recomputation of encryption keys or resubmission of user passwords. This is a significant security advantage since an adversary would need to hack all servers S₀ to S_(n) in the same epoch to compromise system security. The refresh process of this embodiment may also be performed for refreshing any subset of the server keys k_(i), and may therefore be performed for individual authentication servers 3, or for FM server 2 only, if desired.

An exemplary implementation of the above embodiment is described in detail in the following. The implementation is described for a scenario wherein user files are documents uploaded by users for secure storage in system 1. Multiple documents, each identified by a file ID did, can be uploaded by any given user. To accommodate this, the encryption key K_(f), denoted by K_(did) below, for each file further encodes the file ID did for the file. Some preliminaries are described first.

The building blocks for this construction are a hash function H : {0,1}*→{0,1}^(τ) (where*signifies arbitrary length and τ denotes length of the output string), and a one-time-pad style encryption scheme (Enc, Dec) for keys K←{0,1}^(τ). For encryption of a message m under a key K to produce a ciphertext (encrypted file) C, C←Enc(K, m) is defined as C←H*(K) ⊕ m with H*(K) denoting the concatenation of hash outputs created as H(0, K)∥H(1, K)∥ . . . ∥H(1, K)∥ where l is selected such that |H*(K)|≧|m|. Likewise, decryption m←Dec(K, C) works as m←H*(K)|C. For security, a fresh key K is chosen for every message m.

A secure channel between FM server 2 and authentication servers 3 is assumed in this construction. Specifically, communications towards servers 3 are authenticated and communications from servers 3 to FM server 2 are authenticated and confidential (encrypted). In particular, the state leaked to an adversary in a “smash-and-grab” attack on a server does not break security (past or future) of a secure channel. This can be achieved in well-known manner, e.g. using a standard security protocol such as or SSL (Secure Sockets Layer) or TLS (Transport Security Layer) with forward secure encryption and with the secret communication keys of servers and FM server certificates being stored on trusted hardware (e.g. a smart card, HSM (Hardware Security Module), TPM (Trusted Platform Module) or other secure device). Messages between servers may also include appropriate servers IDs and session IDs which are omitted in the following for simplicity.

The setup procedure for this construction comprises initialization, account creation and document creation stages as follows.

FM server S₀ chooses a random key k₀

{0,1}^(τ) and authentication servers S₁ to S_(n) choose random keys k_(i)

{0,1}^(τ).

FM server S₀ creates and account for a user with user ID uid and user password p with the help of authentication servers S₁ to S_(n) as follows.

FM server S₀ sends uid to authentication servers S₁ to S_(n).

Upon receiving uid, each authentication server S_(i) computes a first hash value h_(i) ¹, denoted here by t_(i) ⁰ , as t_(i) ⁰=H(k_(i), (0, uid)), and sends (uid, t_(i) ⁰) to FM server S₀.

Upon receiving (uid, t_(i) ⁰) from all authentication servers S_(i), FM server S₀ computes the user password hash as PH←H(uid, p) ⊕_(i=0) ^(n)t_(i) ⁰ where t₀ ⁰=H(k₀, (0, uid)).

FM server S₀ stores (uid, PH) and deletes all other values, in particular all t_(i) ⁰ values.

FM server S₀ creates an encrypted file C for a user file (doc) with file ID did. The FM server and all authentication servers recompute the password hash, and the FM server checks if the newly derived password hash matches the value PH stored for the user ID. If so, the FM server derives an encryption key K_(f)=K_(did) for the file ID did and encrypts the user file doc.

FM server. On input (uid, p′, doc) from a user for a file doc with allocated file ID did, FM server S₀ sends a “document create” instruction with (uid, did) to authentication servers S₁ to S_(n). This provides a hook for integrating some throttling mechanism at the authentication servers. (Throttling mechanisms are well known in cryptography, providing procedures for monitoring communications for user accounts and determining if any particular user account should be blocked. Throttling mechanisms generally block user accounts if behavior satisfies a predefined criterion indicative of potentially malicious action. For example, a throttling mechanism may be activated for a user account if more than a threshold number of requests are made for the uid within a given time, or are made for a suspiciously large number of user accounts. If such a throttling mechanism is activated, the server logic will refuse to service the request and may send an error message such as “connection was throttled” back to FM server 2

Server S₁ to S_(n). Upon receiving (uid, did) and absent any throttling criterion, each authentication server S_(i) computes the first hash value h_(i) ¹ as t_(i) ⁰=H(k_(i), (0, uid)), and a second hash value h_(i) ², denoted here by t_(i) ¹, as t_(i) ^(1=H(k) _(i), (1, uid, did)), and sends (uid, t_(i) ⁰, t_(i) ¹, to FM server S₀.

FM server: Upon receiving (uid, t_(i) ⁰, t_(i) ¹) from all authentication servers S_(i), FM server S₀ computes the input password hash as PH′←H(uid, p′) ⊕_(i=0) ^(n)t_(i) ⁰ where t₀ ⁰=H (k₀, (0, uid)). If PH≠PH′, abort.

If PH=PH′, choose a random salt s

{0,1}^(τ), derive an encryption key K_(did) as K_(did)=H(uid, p′, did, s), and encrypt the file doc as C←Enc(K_(did), doc).

Mask the used salt s as X=s ⊕_(i=0) ^(n)t_(i) ¹ where to t₀ ¹=H (k₀, (1, uid, did,)).

Compute a “MAC” (Message Authentication Code) of the ciphertext C as Y=H (“MAC”, uid, p′, did, s, C).

Store the document record (uid, did, C, X, Y) in database 6 and delete all intermediate values, in particular all t_(i) ⁰, t_(i) ¹, K_(did), s.

The decryption operation is described by a document retrieval process as follows. The FM server S_(o) and all authenticating servers repeat the process of account creation and the FM server checks if the newly derived password hash PH′ matches the value PH stored for the user ID. If so, the FM server reconstructs the encryption key K_(did) and decrypts the ciphertext C.

FM server. In response to a login request for (uid, p′, did), FM server S₀ sends a login instruction with (uid, did) to authentication servers S₁ to S_(n). This provides the hook for a throttling mechanism at the authentication servers as described above.

Server S₁ to S_(n). Upon receiving (uid, did) and absent any throttling criterion, each authentication server S₁ computes the first and second hash values as t_(i) ⁰=H(k_(i), (0, uid)) and t_(i) ¹=H (k_(i), (1, uid, did)), and sends (uid, t_(i) ⁰, t_(i) ¹) to FM server S₀.

FM server: Upon receiving (uid, t_(i) ⁰, t_(i) ¹) from all authentication servers S_(i), FM server S₀ computes the input password hash as PH′←H(uid, p′) ⊕_(i=0) ^(n)t_(i) ⁰ where t₀ ⁰=H (k₀, (0, uid)). If PH≠PH′, abort. If PH=PH′:

-   -   (a) Reconstruct the salt s as s=X ⊕_(i=0) ^(n)t_(i) ¹ and         compute the encryption key K_(did) as K_(did) H(uid, p′, did,         s).     -   (b) Verify that Y=H (“MAC”, uid, p′ , did, s, C) and, if not,         abort.     -   (c) Decrypt the stored ciphertext as doc←Dec(K_(did), C). Output         doc and delete all intermediate values again, in particular all         t_(i) ⁰, t_(i) ¹, K_(did), s.

The refresh operation is as follows. The secret keys k_(i), user password hashes PH_(j) for all users j, and salt masks X_(k) for all documents k of each user get refreshed.

FM server. FM server S₀ retrieves all user records (uid_(j), PH_(j)) and all document records (uid_(j), did_(k), C_(k), X_(k), Y_(k)). The FM server sends a refresh instruction with {uid_(j), did_(k)} to all authentication servers S₁ to S_(n).

-   -   Server S₁ to S_(n). Upon receiving {uid_(j), did_(k)} do the         following:     -   (a) Choose a fresh random key k_(i)′         {0,1}^(τ).     -   (b) For all uid_(j), compute the first update value U_(i) ¹,         denoted here by u_(i,j) ⁰, as u_(i,j) ⁰←H(k_(i), (0, uid_(j))         ⊕H(k_(i)′(0, uid₁) and compute the second update value U_(i) ²,         denoted here by u_(i,j,k) ¹, as u_(i,j,k) ¹←H(k_(i), (1,         uid_(j), did_(k)) ⊕H(k_(i′, ()1, uid_(j), did_(k))     -   (c) Set k_(i)←k_(i)′, (i.e. delete the old key) and send         {uid_(j), u_(i,j) ⁰, u_(i,j,k) ¹} to FM server S₀.         FM server. On receiving {uid_(j), u_(i,j) ⁰, u_(i,j,k) ¹} from         all servers S₁ to S_(n), update the server key, user records         (uid_(j), PH_(j)) and document records (uid_(j), did_(k), C_(k),         X_(k), Y_(k)) as follows:     -   (a) Choose a fresh random key k₀′         {0,1}^(τ).     -   (b) Update the user password hashes to PH_(j)←PH_(j)⊕_(i=0)         ^(n)u_(i,j) ⁰ with u_(0,j) ⁰←H (k₀, (0, uid_(j))         ⊕H(k₀′(0,uid_(j)).     -   (c) Update the salt masks to X_(k)←X_(k) ⊕_(u=0) ^(n)u_(i,j,k) ¹         with u_(0,j,k) ¹←H(k₀, (1, uid_(j), did_(k)) ⊕ H(k₀′, (1,         uid_(j), did_(k).     -   (d) After all records are updated, set k₀←k₀′ and delete all         intermediate values.

The above construction provides a highly efficient protocol achieving full security against smash-and-grab attacks (where the adversary steals state information, including secret keys, but does not actively control the corrupted server) on up to n servers in any given epoch. The construction also provides selective security against active attacks on the FM server (where the adversary actively controls the server). Selective security means that an adversary can selectively choose records which he later wants to offline attack. However, for each chosen record, the FM server still needs the assistance of all the authentication servers, and the attack can be frustrated by an appropriate throttling mechanism as described above. The authentication servers would then detect suspicious behaviour of a corrupt FM server, e.g., if it tries to decrypt the records of all or at least a significant fraction of users, and refuse to continue their service.

A second preferred embodiment of system 1 will now be described with reference to FIGS. 6 through 8. In this embodiment, the encryption key K_(f) for an encrypted file further encodes the secret server keys More specifically, the secret keys k_(i) of the servers comprise respective key-shares of a secret system key K_(s). This system key K_(s) is not stored in the system but is recomputed as required by combining the key-shares For example, a straightforward way to secret-share a secret key K_(s), being an element of a group G, among servers S₀, . . . , S_(n) is to choose random key-shares k₁, . . . k_(n)←_(R) G and set k₀←K_(s)−Σ_(i=1) ^(n)k_(i). Each server S_(i) is given a key-share k_(i). The key K can then be reconstructed as K_(s)←Σ_(i=0) ^(n)k_(i). In this embodiment, the encryption key K_(f) for each file encodes the system key K_(s) via a combination of the key-shares k_(i). The user password hash PH computed during setup for this embodiment also encodes the system key K_(s) via the predetermined function F which combines the key-shares k_(i) in the first hash values to obtain K_(s). Reconstruction of the encryption key K_(f) for a file involves encoding the input password p′ and the second hash values via which the key-shares k_(i) in these hash values are combined to obtain system key K_(s). FIG. 6 indicates steps of the key-reconstruction operation for decryption of a file in this embodiment. (Again, for simplicity here, operation assumes that a single encrypted file is stored for a given user, but the system is readily extendable to multiple user files as explained below).

The user ID uid and input password p′ supplied by the user are received by FM server 2 in step 60 of FIG. 6. In step 61, the FM server 2 computes each of first and second initial values, denoted here by h and h′. Each initial value h and h′ is produced here via a hash function operating on an input which comprises the input password p′ (and may also include other values as illustrated in the detailed implementation to follow). In step 62, the FM server 2 blinds the initial values h and h′ to produce first and second blinded values, denoted here by u and u′. (Blinding is a widely-used cryptographic procedure whereby a message can be hidden, or blinded, by encoding the message using a selected function, typically combining the message with a random value such as a nonce). In step 63, the FM server sends the blinded values u, u′ to each authentication server server S₁ to S_(n) (i.e. λ=n in this embodiment). In step 64, all servers S₀ to S_(n) compute the first and second hash values h_(i) ¹ and h_(i) ². In this embodiment, the hash values h_(i) ¹ and h_(i) ² respectively comprise the first and second blinded values u and u′ raised to the power of the secret key k_(i) of that server (and may also include other values, such as blinding factors, described further below). In step 65, the n authentication servers S₁ to S_(n) send their hash values h_(i) ¹, h_(i) ² back to FM server 2 . In step 66, the FM server 2 uses the first hash values h_(i) ¹ to compute an input password hash PH′ as the predetermined function F of the input password p′ and the system key K_(S) obtained by combining the key-shares k_(i) via the first hash values. The resulting input password hash PH′ thus comprises the same function F of the input password p′ as used to compute the user password hash PH from the user password p during setup. Next, in step 67, the FM server 2 checks if the input password hash PH′ matches the user password hash PH for the user ID uid. If so, in step 68, the FM server reconstructs the encryption key K_(f) by encoding the input password p′ and the second hash values h_(i) ². The second hash values are combined via this encoding to obtain the system key K_(S) encoded in the encryption key. In step 69, the FM server decrypts the required file using the reconstructed key K_(f), and the operation is complete. If, however, the password hashes PH′ and PH do not match in step 67, then the decryption process is aborted in step 70 and operation terminates.

Use of the shared system key K_(s) in this embodiment allows the secret keys k_(i) to be refreshed by re-sharing the system key between servers S₀ to S_(n). In particular, each server of the system can be adapted to periodically update its secret key k_(i) by addition of a random share δ_(i) of a predetermined value p (most conveniently p=0) which is shared between the servers S₀ to S_(n). The shared system key K_(s) can then still be obtained from a combination of the new key-shares k_(i). Such re-sharing of system key K_(s) could be performed in known manner via interaction of the system servers S₀ to S_(n). For example, for K_(s)←Σ_(i=0) ^(n)k_(i), S₀ could choose random shares δ₁, . . . , δ_(n)←_(R) G, compute δ₀←−Σ_(i=1) ^(n)δ_(i), and send δ_(i) to S_(i). However, in this preferred embodiment, the refresh operation is a simple, non-interactive process, performed unilaterally by each server, in which the key-shares are based on sets of master keys stored by the servers. This exploits a combinatorial secret-sharing scheme in which the random shares 6, are computed in a different way as follows. For all pairs of servers {S_(i), S_(j)}j ≠ i, of the system choose b_({i,j})←_(R) G for all 0≦i≦j≦n and give (b_({i,j}))_(j∓0,j≠i) ^(n) to S_(i) for i=0, . . . , n. Note that there is a share b_({i,j}) for each pair of servers {S_(i), S_(j)}, and that this share is known only to S_(i) and S_(j). Server S_(i) can compute its share of zero δ_(i) as δ_(i)←Σ_(j=0,j≠i) ^(n)Δ_(i,j)·b_({i,j)}, where “·” represents multiplication and Δ_(i,j)=1 if i<j or Δ_(i,j)=−1 otherwise. One can easily see that Σ_(i=0) ^(n)δ_(i)=Σ_(i=0) ^(n)Σ_(j=0,j≠i) ^(n)Δ_(i,j)·b_({i,j})=Σ_(i=0) ^(n)Σ_(j=i+1) ^(n)(b_({i,j})−b_({i,j}))=0 This technique, in which the b_({i,j}) are generated pseudorandomly from a master key known only to servers S_(i) and S_(j), is used to enable each server S_(i) to unilaterally update its key-share k_(i) in this embodiment.

To protect the master keys used in this embodiment, each server S_(i) may comprise first and second server compartments. The first server compartment is connectable to network 5 and is operable, though communication with other servers S_(i) as described above, to implement the key-reconstruction protocol. The second server compartment stores the set of master keys for the server and is inaccessible from network 5 in operation of the authentication protocol. This server compartment can be protected from network 5 by hardware and/or software mechanisms which inhibit unauthorized access to the compartment from the network in operation of the protocol. Such an implementation for the servers S_(i) is illustrated in FIG. 7. The first server compartment 71 of each server comprises a virtual machine 72, denoted by SC1 _(i) ^((ε)) (where ε=0, 1, 2, etc., indicates epoch number), running on a cloud computing platform 73. A fresh virtual machine SC1 _(i) ⁽⁰⁾, SC1 _(i) ⁽¹⁾, SC1 _(i) ⁽²⁾, etc., is initiated on platform 73 for each of successive epochs ε=0, 1, 2, . . . , etc., in operation. Cloud platform 73 may comprise one or more computers each supporting one or more virtual machines. In a typical implementation, cloud platform 73 can be realized by a single physical machine or a cluster of physical machines. The second server compartment 74, denoted by SC2 _(i), comprises a single physical machine in this example. This machine is connected only to the cloud software platform, and such connections can be physically isolated from the network 5 (here assumed to be the Internet) via which the virtual machines 72 communicate. In particular, the virtual machines)SC1 _(i) ⁽⁰⁾, SC1 _(i) ⁽¹⁾, . . . , SC1 _(i) ^((ε)) are exposed to the Internet, while the cloud platform 73 and second compartment SC2 _(i) are run in a protected environment (the “de-militarized zone”), i.e. behind one or more firewalls deployed in the cloud platform.

The second server compartment SC2 _(i) of server 70 stores the set of master keys, denoted by {mk}_(i) in the figure, for the server S_(i). The key set {mk}_(i) for server S_(i) contains master keys (mk_({i,j}))_(j=0, j≠i) ^(n), for all 0≦i<j≦n. Each master key set {mk}_(i) thus contains a respective master key mk_(i,j) common to each other server S_(j), j ≠ i, of system 1. The master key mk_(i,j) will be known only to servers S_(i) and S_(j). The first server compartment SC1 _(i) stores that server's current key-share k_(i) of the system key K_(s). The master key sets {mk}_(i) for servers S_(i) can be provided in an initialization operation of the system. For example, FM server S₀ may generate all master key sets {mk}_(i) which are then communicated to other servers via some secure message transmission functionality F_(smt). This communication may, for example, be implemented by writing the initialization data to a physical medium (such as a USB drive, disc, etc.) which is distributed to server locations by courier and loaded to the servers by an operator. Alternatively, for example, the message transmission functionality F_(smt) may comprise a secure transmission channel established via a standard security protocol such as TLS or SSL.

In operation of system 1 with the server implementation of FIG. 7, time is divided into epochs separated by key refresh procedures performed by the servers. For each epoch ε, a fresh virtual machine SC1 _(i) ^((ε)) is set up, booted, and run on the cloud platform 73 at each server. These machines SC1 _(i) ^((ε)) run the setup and login procedures of the key-reconstruction protocol, and read and write their states from the virtual storage provided to them by cloud platform 73. The second compartment SC2 _(i) of each server controls the cloud platform 73, maintains the images for the virtual machines SC1 _(i) ^((ε)), and prepares the state (stored operating data) that is given to each SC1 _(i) ^((ε)) in order for it to run the protocol procedures.

FIG. 8 indicates steps performed by the second server compartment SC2 _(i) of each server in the refresh operation for a new epoch. In a first step, step 80, of the refresh operation, the SC2 _(i) retrieves its set of master keys {mk}_(i) from memory. In step 81, SC2 _(i) computes a random share δ_(i) of zero from its master key set {mk}_(i). This step uses the combinatorial secret sharing technique explained above to compute δ_(i) as a combination of pseudorandom functions of respective master keys mk_(i,j). In step 82, SC2 _(i) updates the current key-share k_(i) for S_(i) by addition of the random share δ_(i), i.e. set new key-share k_(i)←current key-share k_(i)+δ_(i). The new key-shares k_(i) of all servers S_(i) are thus independent of those in the previous epoch, but the sum Σ_(i=0) ^(n)k_(i)=K_(S) remains constant. In step 83, SC2 _(i) supplies the new key-share k_(i) to the first server compartment SC1 _(i) for the new epoch. Through use of the master keys in this way, each server S_(i) can unilaterally generate new key shares in operation, whereby proactive security is achieved without requiring communication between servers for the key refresh process.

An exemplary implementation for this embodiment is described in detail in the following. Here, again, user files are documents uploaded by users for secure storage, whereby multiple documents, each identified by a file ID did, can be uploaded by any given user. The encryption key K_(f)=K_(did) for each file thus further encodes the file ID did for that file. Some preliminaries are described first.

H : {0,1}*→G and G : {0,1}*→{0,1}^(τ) are two independent hash functions. We will also need additional independent hash functions G′: {0,1}*→{0,1}^(τ), C : z_(q)→{0,1}^(2τ), B₀ : {0,1}^(τ)×N→G, B₁ : {0,1}^(τ)×N→G, B₂ : {0,1}^(τ)×N→G, and B₃ : {0,1}^(τ)×N→z_(q) modelled as random oracles. Let G be a multiplicative group of prime order q>2^(2τ) with generator g. Let PRF₀ : {0,1}^(τ)×N→z_(q), PRF₁ : {0,1}^(τ)×N→{0,1}^(τ) be pseudorandom functions and let MAC : {0,1}^(τ)×{0,1}*→T be a message authentication code.

The setup procedure for this construction comprises initialization, account creation and document creation stages detailed below. During initialization, all parties can communicate over the secure message transmission functionality F_(smt) discussed above. Afterwards, they communicate over an untrusted network, where messages can be arbitrarily observed, modified, and delayed by the adversary, but all messages are integrity-protected with a MAC. The protocol provides FM server S₀ with a shared MAC key μ_(i) with each server S_(i), i=1 to n. Whenever the description below says that FM server S₀ sends m to S_(i), this means that S₀ computes T←MAC(μ_(i), m) and sends (m, T) to S_(i). Similarly, when S_(i) receives m from S₀, this means that S_(i) receives (m, T) and checks that T=MAC(μ_(i), m), ignoring the message m if not. The communication in the other direction from server S_(i) back to S₀ is protected in the same way with the same MAC key μ_(i). Messages may also include appropriate servers IDs and session IDs which are omitted in the following for simplicity.

Each server S_(i), i=0 to n, maintains a list of blinding seeds s_({i,j}) for j=0 to n, j ≠ i. The blinding seeds s_({i,j}) of each server S_(i) are computed as pseudorandom functions of respective master keys mk_(i,j) as detailed below. The blinding seeds are used to generate random shares of the unity element in G or of zero in z_(q) using a combinatorial secret sharing scheme. In each account creation or login session, the servers S_(i) derive fresh shares β_(i,0), . . . , β_(i,3) of unity or zero using the hash functions B₀, . . . , B₃ applied to s_({i,j}) and a sub-session identifier ssid, and use these shares as blinding factors for their protocol messages so that Π_(i=0) ^(n)β_(i,k)=1 for k=0, 1, 2 and Σ_(i=0) ^(n)β_(i,3)=0. More precisely, S_(i)'s blinding factors are computed as β_(i,k)←Π_(j=0,j≠i) ^(n), B_(,)(s_({i,j}), ssid)^(Δ) ^(i,j) for k=0, 1, 2 and as β_(i,3)←Σ_(j=0,j≠i) ^(n)Δ_(i,j)B₃(s_({i,j}), ssid) mod q, where Δ_(i,j)32 1 if i<j and Δ_(i,j)=1 otherwise.

Each server's key-share k_(i) and blinding seeds s_({i,j}) can form part of the state information st_(i) provided to first server compartment SC1 _(i) of server S_(i) in FIG. 7. The master keys for S_(i) can form part of the stored data backup, held in the (trusted) memory backup of second server compartment SC2 _(i).

During initialization, all servers are running in a trusted execution environment, have access to the backup memory backup, and can communicate through the secure message transmission functionality F_(smt).

FM Server S₀: The FM server generates and distributes master keys mk_({i,j}) ^(b) for all servers in the system. It also generates a secret system key K_(s)=K for a joint public key L and uses the master keys to compute its own initial key-share k₀ of K, as well as its initial blinding seeds s_({0,j}). The key-share and blinding seeds are part of S₀'s initial state and the master keys are kept in the backup memory backup.

-   -   (a) Set an epoch counter epoch←0.     -   (b) For all subsets S={i, j} for i, j={0, . . . , n}, i ≠ j,         choose master keys mk_(s) ⁰, mk_(s) ¹←^($){0,1}^(Σ).     -   (c) Choose K ←^($)z_(q) and set L←g^(K). Compute δ₀ ←Σ_(j=1)         ^(n)PRF₀(mk_({0,J}) ⁰, epoch) mod q. Set k₀←K+δ₀ mod q.     -   (d) For all j=1, . . . , n, compute blinding seeds         s_({0,j})←PRF₁(mk_({0,j}) ¹, 2·epoch), and MAC keys         μ_(j)←PRF₁(mk_({0,j}) ¹, 2·epoch+1).     -   (e) Store backup₀←(epoch, k₀, (mk_({0,j}) ^(b=0,1))_(j=1)         ^(n), L) in backup memory. Set initial state st₀ of S₀ to         st₀←(epoch, k₀, (s_({0,j}))_(j=1) ^(n), (μ_(j))_(j=1) ^(n), L).     -   (f) For i=1, . . . , n, securely send (mk_({i,j})         ^(b=0,1))_(j=0,j≠i) ^(n) to server S_(i) via F_(smt).

Authentication Servers S_(i)=S₁ to S_(n): Each server stores the received master keys mk_({i,j}) ^(b) in backup memory and derives its initial key-share k_(i) and blinding seeds s_({i,j}).

-   -   (a) On receiving (mk_({i,j}) ^(b=0,1))_(j=0,j≠i) ^(n)via         F_(smt), set epoch←0.     -   (b) Compute δ_(i)←Σ_(j=0,j≠i) ^(n)Δ_(i,j)PRF₀(mk_({i,j}) ⁰,         epoch) mod q and set initial key-share to k_(i)←δ_(i).     -   (c) For all j=0, . . . , n, j ≠ i, compute blinding seeds         s_({i,j}←)PRF₁(mk_({i,j}) ¹, 2·epoch), and MAC key         μ_(i)←PRF₁(mk_({0,i}) ¹, 2·epoch+1).     -   (d) Store backup_(i) ←(epoch, k_(i), (mk_({i,j})         ^(b=0,1))_(j=0,1≠i) ^(n)) in backup memory and set initial state         st_(i) of S_(i) to st_(i) ←(epoch, k_(i), (s_({i,j}))_(j=0,j≠i)         ^(n), μ_(i)).

FM server S_(o) creates an account for a user with user ID uid and user password p with all n authentication servers as follows.

FM Server S₀: The FM server sends a blinded initial hash value and challenge hash to all servers S₁ to S_(n).

-   -   (a) On input (uid, p) compute an initial hash value h as         h=H(uid, p). Generate a random nonce N         z_(q) and a random challenge c         z_(q). Compute a blinded value as u←h^(N) and ch←C(c).     -   (b) Send (ssid, u, ch) to all S₁ to S_(n), where ssid is a         sub-session identifier.     -   (c) Store (uid, p, N, u, c) associated with ssid.

Authentication Servers S_(i)=S₁ to S_(n): Each server sends a blinded response (first hash value v_(i)) using its secret key-share k_(i), and the blinded first move of a zero-knowledge proof.

-   -   (a) On receiving (ssid, u, ch) from S₀, compute v_(i)←u^(k) ^(i)         β_(i,0), where β_(i,0)=Π_(j=0,j≠i) ^(n)B₀(S_({i,j}), ssid)^(Δ)         ^(i,j) .     -   (b) Choose r_(i)         z_(q) and compute R_(1,i)←g^(r) ^(i) ·Π_(j=0,j≠i)         ^(n)B₁(s_({i,j}), ssid)^(Δ) ^(i,j) and         R_(2,i)←u^(r) ^(i) ·Π_(j=0,j≠i) ^(n)B₂(S_({i,j}), ssid)⁶⁶ ^(i,j)         .     -   (c) Respond by sending (ssid, v_(i), R_(1,i), R_(2,i) ) to S₀.     -   (d) Store (r_(i), ch) associated with ssid.

FM Server S₀: The FM server sends the challenge for the zero knowledge proof.

-   -   (a) On receiving (ssid, v_(i), R_(1,i), R_(2,i)) from all         servers S₁ to S_(n), retrieve (uid, p, N, u, c) associated with         ssid.     -   (b) Update the information stored with ssid to (uid, p, N, u, c,         (v_(i), R_(1,i),R_(2,i))_(i=1) ^(n))).     -   (c) Send (ssid, c) to all servers S₁ to S_(n).

Authentication Servers S_(i)=S₁ to S_(n): Each server checks the challenge hash from the previous round and sends the blinded last move of a zero-knowledge proof.

-   -   (a) On receiving (ssid, c) from S₀, retrieve (r_(i), ch)         associated with ssid. Abort if it does not exist.     -   (b) If C(c)≠ ch, abort.     -   (c) Compute s_(i)←k_(i)c+r_(i)+Σ_(j=0,j≠i) ^(n),         Δ_(i,j)B₃(S_({i,j}), ssid) mod q.     -   (d) Respond by sending (ssid, s_(i)) to S₀. Remove all         information associated to ssid.

FM Server S₀: The FM server verifies the aggregated server contributions through the zero knowledge proof and computes the user password hash.

-   -   (a) On receiving (ssid, s_(i)) from all servers S₁ to S_(n),         retrieve (uid, p, N, u, c, (v_(i), R_(1,i), R_(2,i) ) _(i=1)         ^(n)) stored for ssid. Abort if it does not exist.     -   (b) Compute first hash value v₀←u^(k) ⁰ ·Π_(j=1)         ^(n)B₀(s_({0,j}), ssid)^(Δ) ^(0,j) . Choose r₀         z_(q), compute R_(1,0)←g^(r) ⁰ ·Π_(j=1) ^(n)B₁(s_({0,j}),         ssid)^(Δ) ^(0,j) and R_(2,0)←u^(r) ⁰ ·Π_(j=1) ^(n)B₂(S_({0,j}),         ssid)^(Δ) ^(0,j) Also compute s₀←k₀c+r₀+Σ_(j=1)         ^(n)Δ_(i,j)B₃(S_({0,j}), ssid) mod q.     -   (c) Compute v←Π_(i=0) ^(n)v_(i) ^(1/N), R₁←Π_(i=0) ^(n)R_(1,i),         R₂←Π_(i=0) ^(n)R_(2,i) and s←Σ_(i=0) ^(n)s_(i) mod q.

Verify that g^(s)=L^(c)R₁ and u^(s)=v^(Nc)R₂ and if not abort.

-   -   (d) Store PH=G(uid, p, v) as the user password hash for uid.         Remove all information associated to ssid.

The zero-knowledge proof in the above procedure ensures that all servers have correctly used their key-shares k_(i) for computation of the user password hash PH.

FM server S₀ creates an encrypted file C for a user file (doc) with file ID did. The FM server first checks if password hash is correct and then derives a new encryption key K_(f)=K_(did).

FM Server S₀: The FM server sends first and second blinded hash values to all servers.

-   -   (a) On input (uid, p′, doc) for a file doc allocated file ID         did, compute first and second initial values h and h′ as         h=H(uid, p′) and h′ =H(uid, p′, did). Generate random nonces N,         N′         z_(q) and a random challenge c         z_(q).     -   (b) Compute first and second blinded values as u←h^(N) and         u′←h′^(N), and ch←C(c).     -   (c) Send (ssid, u, u′, ch) to all S₁ to S_(n).     -   (d) Store (uid, p′, N, u, N, u′, c) associated with ssid.

Authentication Servers S_(i)=S₁ to S_(n): Each server sends blinded responses (first and second hash values v_(i), v_(i)′) using its secret key-share k_(i), and the first move of a zero-knowledge proof.

-   -   (a) On receiving (ssid, u, u′, ch) from S₀, compute v_(i)←u^(k)         ^(i) ·Π_(j=0,j≠i) ^(n)B₀(s_({i,j}), ssid, 0)^(Δ) ^(i,j) and         v_(i)′←u′^(k) ^(i) ·Π_(j=0,j≠i) ^(n)B₀(s_({i,j}), ssid, 1)^(Δ)         ^(i,j)     -   (b) Choose r_(i)         z_(q) and compute R_(1,i)←g^(r) ^(i) ·Π_(j=0,j≠i)         ^(n)B₁(s_({i,j}), ssid)^(Δ) ^(i,j) and         R_(2,i)←u′^(r) ^(i) ·Π_(j=0,j≠i) ^(n)B₂(S_({i,j}), ssid)^(Δ)         ^(i,j)     -   (c) Respond by sending (ssid, v_(i), v_(i)′, R_(1,i), R_(2,i))         to S₀.     -   (d) Store (r_(i), ch) associated with ssid.

FM Server S₀. The FM server verifies the recomputed input password hash PH′ against the stored user password hash PH and sends the challenge for the zero-knowledge proof.

-   -   (a) On receiving (ssid, v_(i), v_(i)′, R_(1,i), R_(2,i)) from S₁         to S_(n), retrieve (uid, p′, N, u, N′, u′, c) associated with         ssid. Abort if it does not exist.     -   (b) Compute first hash value v₀←u^(k) ⁰ ·Π_(j=1)         ^(n)B₀(s_({0,j}), ssid)^(Δ) ^(0,j) and v←Π_(i=0) ^(n)v_(i)         ^(1/N).     -   (c) Compute PH′=G(uid, p′, v). If PH′ ≠ PH, then abort and         delete (uid, p′, N, u, N′, u′, c) for ssid.     -   (d) If PH′=PH, update the information stored with ssid to (uid,         p′, N′, u′, c, (v_(i)′, R_(1,i), R_(2,i))_(i=1) ^(n))) and send         (ssid, c) to S₁ to S_(n).

4. Authentication Servers S_(i)=S₁ to S_(n): Each server checks the challenge hash from the previous round and sends the blinded last move of a zero-knowledge proof.

-   -   (a) On receiving (ssid, c) from S₀, retrieve (r_(i), ch)         associated with ssid. Abort if it does not exist.     -   (b) If C(c)≠ ch, abort.     -   (c) Compute s_(i)←k_(i)c+r_(i)+Σ_(j=0,j≠1)         ^(n)Δ_(i,j)B₃(s_({i,j}), ssid) mod q.     -   (d) Respond by sending (ssid, s_(i)) to S₀. Remove all         information associated to ssid.

FM Server S₀: The FM server verifies the aggregated server contributions through the zero knowledge proof, computes the document key and encrypts the document.

-   -   (a) On receiving (ssid, s_(i)) from S₁ to S_(n), retrieve (uid,         p, N′, u′, c, (v_(i)′, R_(1,i), R_(2,i))_(i=1) ^(n)) stored for         ssid. Abort if it does not exist.     -   (b) Compute second hash value v₀′←u′^(k) ⁰ ·Π_(j=1)         ^(n)B₀(s_({0,j}), ssid)^(Δ) ^(0,j) . Choose r₀         z_(q), compute R_(1,0)←g^(r) ⁰ ·Π_(j=1) ^(n)B₁(s_({0,j}),         ssid)^(Δ) ^(0,j) and R_(2,0)←u′^(r) ⁰ ·Π_(j=1) ^(n)B₂(S_({0,j}),         ssid)^(Δ) ^(0,j) Also compute s₀←k₀c+r₀+Σ_(j=1)         ^(n)Δ_(i,j)B₃(s_({0,j}), ssid) mod q.     -   (c) Compute v′←Π_(i=0) ^(n)v′_(n) ^(1/N)′, R₁←Π_(i=0)         ^(n)R_(1,i), R₂←Π_(i=0) ^(n)R_(2,i) and s←Σ_(i=0) ^(n)s_(i) mod         q.

Verify that g_(s)=L^(c)R₁ and u′^(s)=v′^(N′c)R₂ and if not abort.

-   -   (d) Derive an encryption key K_(did) as K_(did)←G′(uid, p′, did,         v′), and encrypt the file doc as C←Enc(K_(did), doc).     -   (e) Store the document record (uid, did, C) and delete all other         information for ssid.

The login protocol is a simplified version of account and document creation without the zero-knowledge proofs.

FM Server S₀: The FM server sends first and second blinded values to all servers.

-   -   (a) On input (uid, p′, did), compute first and second initial         values h and h′ as h=H(uid, p′) and h′=H(uid, p′, did). Generate         random nonces N, N′         z_(q) and compute first and second blinded values as u←h^(N) and         u′←h′^(N).     -   (b) Send (ssid, u, u′) to S₁ to S_(n).     -   (c) Store (uid, p′, N, u, N, u′) associated with ssid.

Authentication Servers S_(i)=S₁ to S_(n): Each server sends blinded responses (first and second hash values v_(i), v_(i)′) using its secret key-share k_(i).

-   -   (a) On receiving (ssid, u, u′) from S_(o), compute v_(i)←u^(k)         ^(i) ·Π_(j=0,j≠i) ^(n)B₀(S_({i,j}), ssid, 0)^(Δ) ^(i,j) ′ and         v_(i)′←u′^(k) ^(i) ·Π_(j=0,j≠i) ^(n)B₀(s_({i,j}), ssid, 1)^(Δ)         ^(i,j)     -   (b) Respond by sending (ssid, v_(i), v_(i)′) to S₀.

FM Server S₀. The FM server verifies the recomputed input password hash PH′ against the user password hash PH and decrypts the document.

-   -   (a) On receiving (ssid, v_(i), v_(i)′) from S₁ to S_(n),         retrieve (uid, p′, N, u, N′, u′) associated with ssid. Abort if         it does not exist.     -   (b) Compute first hash value v₀←u^(k) ⁰ ·Π_(j=1)         ^(n)B₀(s_({0,j}), ssid, 0)^(Δ) ^(0,j) and v←Π_(i=0) ^(n)v_(i)         ^(1/N). Also compute second hash value v₀′←u′^(k) ⁰ ·Π_(j=1)         ^(n)B₀(s_({0,j}), ssid, 1)^(Δ) ^(0,j) and v′←Π_(i=0) ^(n)v′_(i)         ^(1/N)′.     -   (c) Compute PH′=G(uid, p′, v). If PH′ ≠ PH, then abort and         delete all information for ssid.     -   (d) If PH′=PH, compute the encryption key K_(did) as K_(did) p′,         did, v′) and decrypt the stored ciphertext as doc←Dec(K_(did),         C). Output doc and delete all information for ssid.

Refresh takes place in a trusted environment with access to the backup memory.

FM Server S₀: Based on its backup backup₀ and current state st₀, S₀ computes its new state.

-   -   (a) Recover backup₀=(L, k₀, (mk_({0,j}) ^(b=0,1))_(j=1) ^(n),         epoch,) and current state st₀=(epoch, k₀, (s _({0,j}))_(j=1)         ^(n), *μ_(j))_(j=1) ^(n), L)     -   (b) Increase the epoch count to epoch←epoch+1. Compute         δ₀←Σ_(j=1) ^(n)PRF₀(mk_({0,J}) ⁰, epoch) mod q. Set new key         share k₀←current key share k₀+δ₀.     -   (c) For all j=1, . . . , n, compute new blinding seeds         s_({0,j})←PRF₁(mk_({0,j}) ¹, 2·epoch), and new MAC keys         μ_(j)←PRF₁(mk_({0,j}) ^(n), 2·epoch+1).     -   (e) Store new backup₀←(L, k₀, (mk_({0,j}) ^(b=0,1))_(j=1) ^(n),         epoch) in backup memory. Set new state of S₀ to st₀←(k₀,         (μ_(j))_(j=1) ^(n), (s_({0,j}))_(j=1) ^(n), epoch, L).

Authentication Servers S_(i)=S₁ to S_(n): Each server computes its new state st_(i) based on its backup backup_(i).

-   -   (a) Recover backup_(i)=(epoch, k_(i), (mk_({i,j})         ^(b=0,1))_(j=0,j≠i) ^(n),)     -   (b) Set epoch∂epoch+1. Compute δ_(i)←Σ_(j=0,j≠i)         ^(n)Δ_(i,j)·PRF₀(mk_({i,j}) ⁰, epoch) and set new key share         k_(i)←current key share k_(i)+δ_(i) mod q.     -   (c) For j=0, . . . , n, j ≠ i, compute new blinding seeds         s_({i,j})←PRF₁(mk_({i,j}) ¹, 2·epoch), and new MAC keys,         μ_(i)←PRF₁(mk_({0,i}) ¹, 2·epoch+1).     -   (e) Store new backup_(i)←(epoch, k_(i), (mk_({i,j})         ^(b=0,1))_(j=0,j≠i) ^(n)) in backup memory. Set new state of         S_(i) to st_(i)←(epoch, k_(i), (s_({i,j}))_(j=0,j≠i) ^(n),         μ_(i)).

The above construction provides an exceptionally secure protocol, achieving full security even against active attacks on the system servers. An adversary corrupting at most n servers (out of the FM server and the n authentication servers) per epoch cannot offline attack any of the encrypted data by trying to guess the password.

Many changes and modifications can of course be made to the exemplary embodiments described. For example, while the second embodiment is described for a so-called “n-out-of-n” key-sharing scheme (in which all key-shares k_(i) are used to reconstruct the shared key K_(s), embodiments based on “t-out-of-n” (threshold) schemes can be envisaged. Here only t key-shares are required to reconstruct K_(s), whereby the FM server need only communicate with λ=t1 authentication servers for document retrieval. For instance, Shamir's secret sharing scheme allows a secret key K ∈ G to be shared among a set of servers S₁, . . . , S_(n) so that any subset of size t can recover K. Shamir's approach underlies almost all practical t-out-of-n threshold cryptography schemes. The dealer (e.g., S₁) chooses a random polynomial f(x) of degree t-1 such that f(0)=K, for example, by choosing random coefficients a₁, . . . , a_(t-1)←_(R) G and letting f(x)=K+a₁x+. . . +a_(t-1)x^(t-1). The dealer hands S_(i) its key share K_(i)=f(i). Given t different points (i, K_(i)) of the polynomial for S₁ ⊂{1, . . . , n}, #S=t, one can use Lagrange interpolation to reconstruct the polynomial as

${f(x)} = {\sum_{i \in S}{\prod_{j \in {S\backslash{\{ i\}}}}{\frac{x - j}{i - j}K_{i}}}}$ and therefore recompute the key K=f(0) as K=Π_(i∈S)λ_(S,i)K_(i) where λ_(S,i) are the Lagrange coeffcients λ_(S,i)=Π_(j∈S\{i})j(j-i).

Server implementations for the first embodiment above may be based on the implementation of FIG. 7, and various other server implementations can be envisaged. For example, the initialization data (master keys, etc.) generated by S₀ in the above scheme could be written to a secure device such as a smart card, HSM, TPM or similar device which is then distributed to the other servers. This device may then also implement the required functionality of the second server compartment SC2 _(i). Embodiments might also be envisaged where the second server compartment SC2 i is implemented by a hypervisor controlling operation of one or more virtual machines providing the first server compartment SC1 i.

In general, values described as encoding specified elements may encode further elements if desired. The second embodiment can also be modified to accommodate shared values which are constants other than unity or zero in calculating the blinding factors and key-shares.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. 

What is claimed is:
 1. A server system comprising a file management server for communication with user computers via a network and managing encrypted files, each encrypting a user file associated with a user ID under a respective encryption key K_(f)encoding a user password associated with that user ID, and n≧1 authentication servers for communication with the file management server via the network, wherein: each file management server of the system stores a respective secret key k_(i); the file management server stores, for each the user ID, a user password hash comprising a predetermined function of the user password associated with that user ID and the secret keys k_(i); and the file management servers of the system are adapted such that, in response to receipt from the user computer of an input password and the user ID for a required encrypted file, the file management server communicates with λ authentication servers, 1≦λ≦n, to implement a key-reconstruction protocol in which each file management server computes first and second hash values, including the secret key k_(i), thereof, for the required encrypted file; the file management server uses the first hash values to compute an input password hash comprising the predetermined function of the input password and the secret keys k_(i) checks if the input password hash matches the user password hash for a received user ID, and, if so, reconstructs the encryption key K_(f) for the required encrypted file, the reconstructed key K_(f) encoding the input password and the reconstruction requiring use of the second hash values, the file management server decrypts the required encrypted file using the reconstructed key K_(f); the encryption key K_(f), further encodes a random salt s for the encrypted file; the file management server stores a salt mask X which encodes the salt s and the second hash values; and the file management server is adapted, in the key-reconstruction protocol, to reconstruct the salt s from the salt mask X and the second hash values computed by the servers, and to reconstruct the encryption key K_(f) by encoding the input password and the reconstructed salt; each file management server of the system is adapted to periodically replace a current secret key k_(i), thereof with a new secret key, and to compute first and second update values for each encrypted file, the first update value being a modulo-2 sum of the first hash value computed using the current secret key and the first hash value computed using the new secret key, and the second update value being a modulo-2 sum of the second hash value computed using the current secret key and the second hash value computed using the new secret key; and the file management server is adapted to update the user password hash for the encrypted file by modulo-2 addition with the first update value, and to update the salt mask X for the encrypted file by modulo-2 addition with the second update value.
 2. A system as claimed in claim 1 wherein the file management server is adapted to communicate with λ=n authentication servers to implement the key reconstruction protocol.
 3. A system as claimed in claim 1 wherein: the salt mask X comprises a modulo-2 sum of the salt s and the second hash values; and the user password hash comprises a modulo-2 sum of an initial hash value, encoding the user password, and the first hash values.
 4. A system as claimed in claim 1 wherein, in the key-reconstruction protocol: the file management server sends the received user ID via the network to the λ authentication servers; and each file management server computes the first and second hash values using the received user ID and the current secret key k_(i), of that server.
 5. A system as claimed in claim 4 wherein the encryption key K_(f) further encodes a file ID for the encrypted file, and, in the key-reconstruction protocol: the file management server sends the received user ID and the file ID for the required encrypted file via the network to the λ authentication servers; and each file management server computes the second hash value using the received user ID, the file ID and the current secret key k_(i), of that server.
 6. A system as claimed in claim 1 wherein the encryption key K_(f) further encodes the secret keys k_(i) of the servers, and the file management server is adapted, in the key-reconstruction protocol, to reconstruct the encryption key K_(f) by encoding the input password and the second hash values.
 7. A system as claimed in claim 6 wherein: the secret keys k_(i) of the servers comprise respective key-shares of a secret system key K_(s); the encryption key K_(f) encodes the system key K_(s); and the user password hash encodes the system key K_(s) via the predetermined function.
 8. A system as claimed in claim 7 wherein each server of the system is adapted to periodically update the secret key k_(i) thereof by addition of a random share of a predetermined value p which is shared between the servers of the system.
 9. A system as claimed in claim 8 wherein p=0.
 10. A system as claimed in claim 8 wherein each server S_(i) of the system further stores a set of master keys which comprises a respective master key common to each other server S_(j), j≠i, of the system, and wherein the random share comprises a combination of pseudorandom functions of respective master keys which is computed unilaterally by that server.
 11. A system as claimed in claim 7 wherein, in the key-reconstruction protocol: the file management server computes each of first and second initial values via a hash function operating on the input password, blinds the first and second initial values to produce first and second blinded values respectively, and sends the first and second blinded values via the network to the λ authentication servers; and the first and second hash values computed by each file management server respectively comprise the first and second blinded values raised to the power of the current secret key k_(i), of that server.
 12. A system as claimed in claim 11 wherein the encryption key K_(f) further encodes a file ID for the encrypted file, and wherein the file management server computes the second initial value via the hash function operating on the input password and the file ID for the required encrypted file.
 13. A method for managing encrypted files, each encrypting a user file associated with a user ID under a respective encryption key K_(f) encoding a user password associated with that user ID, at a file management server of a server system including n≧1 authentication servers, the file management server being adapted for communication with user computers and the authentication servers via a network, and each file management server of the system storing a respective secret key k_(i) the method comprising, at the file management server: storing, for each the user ID, a user password hash comprising a predetermined function of the user password associated with that user ID and the secret keys k_(i); in response to receipt from a user computer of an input password and a the user ID for a required encrypted file, communicating with λ authentication servers, 1≦λ≦n, to implement a key-reconstruction protocol in which each file management server computes first and second hash values, including the secret key k_(i), thereof, for the required encrypted file, and the file management server uses the first hash values to compute an input password hash comprising the predetermined function of the input password and the secret keys k_(i) checks if the input password hash matches the user password hash for a received user ID, and, if so, reconstructs the encryption key K_(f) for the required encrypted file, the reconstructed key K_(f) encoding the input password and the reconstruction requiring use of the second hash values, and decrypts the required encrypted file using the reconstructed key K_(f), wherein the encryption key K_(f) further encodes a random salt s for the encrypted file, the method including, at the file management server: storing a salt mask X which encodes the salt s and the second hash values; in the key-reconstruction protocol, reconstructing the salt s from the salt mask X and the second hash values computed by the servers, and reconstructing the encryption key K_(f) by encoding the input password and the reconstructed salt; each file management server of the system is adapted to periodically replace a current secret key k_(i), thereof with a new secret key, and to compute first and second update values for each encrypted file, the first update value being a modulo-2 sum of the first hash value computed using the current secret key and the first hash value computed using the new secret key, and the second update value being a modulo-2 sum of the second hash value computed using the current secret key and the second hash value computed using the new secret key; and the file management server is adapted to update the user password hash for the encrypted file by modulo-2 addition with the first update value, and to update the salt mask X for the encrypted file by modulo-2 addition with the second update value.
 14. A method as claimed in claim 13 wherein the salt mask X comprises a modulo-2 sum of the salt s and the second hash values, and the user password hash comprises a modulo-2 sum of an initial hash value, encoding the user password, and the first hash values.
 15. A method as claimed in claim 13 wherein the encryption key K_(f) further encodes the secret keys k_(i) of the servers, the method including, at the file management server: reconstructing the encryption key K_(f) in the key-reconstruction protocol by encoding the input password and the second hash values.
 16. A method as claimed in claim 15 wherein the secret keys k_(i) of the servers comprise respective key-shares of a secret system key K_(s), the encryption key K_(f) encodes the system key K_(s), and the user password hash encodes the system key K_(s) via the predetermined function. 